fix(DEPLOY-005): resolve pinned universe sources from the repo, not DATA_DIR - #116

The defect

refresh_universe_files() could not rebuild the three Hemant universes in any deployment that sets DATA_DIR.

Their pinned source lists were resolved from UNIVERSE_DIR, which follows DATA_DIR. But COPY . . puts those lists at /app/data/universes/, so a container with DATA_DIR=/data looked on the data volume instead and raised:

FileNotFoundError: Universe source CSV not found: /data/universes/hemant_super_45.csv

Two blast radii

1. The daily-scan cron never ran. render.yaml runs it as sh -c "python -c '...refresh_universe_files()' && run_daily_scan" on an ephemeral filesystem with no disk at all (render.yaml:95). So /data was empty every run, the refresh raised, and && meant the scan was skipped. Every night.
2. First-deploy seeding failed. docs/operations.md:912 tells the operator to run that exact command in a Render Shell to populate the empty disk.

The blueprint comment shows how the gap was reasoned into existence — "the nifty/fno lists are downloaded, not baked into the image". True for NIFTY/F&O; the Hemant lists are baked in, just at a path nothing looked at. That comment is corrected here.

The fix

Separate the two concerns onto different anchors:

• inputs — UNIVERSE_SOURCE_DIR, anchored to PROJECT_ROOT: pinned, reviewed, shipped inside the image. New data/universes/sources/*.csv, extracted verbatim from the existing source_symbol values, so counts and ordering are unchanged (43 / 43 / 262, and the existing pinned-snapshot assertions on the last three tokens still hold).
• outputs — UNIVERSE_DIR, still following DATA_DIR onto the data volume.

This also closes a second-order smell the coupling caused: source and output being one path meant every refresh rewrote the file it had just read, so the working tree went dirty after any app run, and every committed row carried an absolute developer path in its source column. repo_relative_source_label() now stores a repo-relative POSIX label, and the three committed CSVs are rewritten accordingly — that diff is the source column only.

On the regression test

It runs in a subprocess with a relocated DATA_DIR, and that is deliberate rather than lazy: the faulty binding happened at import time, so monkeypatching the environment inside an already-imported process would have proved nothing. A fresh interpreter is exactly what the Render cron and docker compose give us.

Verified failing before this change with the exact production error above, and passing after.

Verification

• pytest -q --cov=... --cov-fail-under=89 — 2037 passed, 1 skipped, 89.96%
• ruff check, compileall, bandit — clean
• git diff origin/main HEAD -- constraints.txt pyproject.toml — empty (AGENTS.md §7)
• origin/main merged in and all gates re-run after PRs fix(DATA-003): stop the scan re-dirtying the candle cache it just repaired #112/fix(DATA-004): stop re-downloading stocks that listed after the window opened #114 landed

Caveat, stated plainly: this was traced statically through committed files and reproduced in-process. Docker is not installed on the development machine, so the container-level run was not performed. If the Render blueprint was never applied, the defect was latent rather than live.

Docs updated: universe-management LLD (including a new design-decision row), render.yaml, docs/operations.md, README.md.

🤖 Generated with Claude Code